Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1014

Internet Message Format | 1994-08-27 | 3.8 KB

Date: Mon, 25 Jul 1994 13:44:47 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: GEM apps, in general
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407251347.D1140-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Warwick:

]>I found a better way [of scrolling background windows] that involved
]>another bitmap elsewhere in memory.  It was easier, cleaner, and faster.
]
]Yikes!  Be careful!  On most graphics hardware, excluding std ST/TT stuff,
]screen-to-screen blitting is MUCH faster than blitting from a bitmaps held
]off-screen.  Also, holding offscreen bitmaps gets extremely expensive as
]the depth of the display increases.  For example, a small 200x200 bitmap
]is 120K on a 24bit display!

I can see what you're saying.  A duplicate screen would be rather memory
expensive.  Nevertheless, what I did was still noticably faster... PLUS
it kept track of the contents of the window for when I had to redraw a
section.

]>Are the icons on the desktop part of a desktop form?  If so, how do
]>programs get away with replacing the the background without removing the
]>desktop's object tree?
]
]It DOES remove the desktop's tree.  That's why you really should avoid it
]for MTOS apps.  Each time you change application (eg. top a window), the
]menubar and any installed desktop gets changed.  The menubar change is fast,
]fine, and obvious, but the desktop change is quite disconcerting.

Since it removed the desktop form, why do the icons still show up?


I'll have to get Interface some time.  How much does it cost and who puts
it out?


Ofir:

]Personally, I'm fed up with this nonsense about who's library is better. At
]last Tim Miller is talking some sense and we have to put up with this new
]waste of bandwidth.

Which waste of bandwidth?  Mine or theirs?

And, I really don't like your remark about me 'at last making some
sense'.  If you ask me, I've always been making sense.  I have good
reasons for not wanting something as dangerous as select-all being
assigned to something as frequently acceidentally hit as Ctrl-A.  It
makes sense to be CAREFUL when designing a user iterface!


Kevin:

]Yeah, come on guys - can we not have a discussion on GUIs without bringing
]each other's toolkits into it?

Bringing up one's toolkit is just fine.  It's the 'mine is better than
yours' arguement that is the problem, although that isn't all bad in and
of itself... it causes the parties involved to learn some things they
might not have known.  It would be best, though, if much of the bickering
were in private email.  Even so, I have learned a great deal from their
bickering.



]> Definately a dangerous practice.  Keys should only go to the top window.
]> Period.  Clicking in a background window can be confusing enough.
]>
]Surely it should be up to the user how this sort of thing behaves. Whilst
]conceptually it might appear dangerous I've never had any problems working
]in an environment like that for quite a number of years.

You CANNOT leave everything up to the user!  If you did, the
configuration woule be hell with countless options that must users
wouldn't understand, and the executables would be HUGE with libraries
with code for every conceivable option.  Plus, the library developer
can't think of EVERYTHING.

Sure, some things would be nice as configurable, but we know more about
userinterfaces than the average user (for the most part), and we can
figure out what works well as compared to what is absolutely moronic.

Some times, you just have to make the decision for the user do he can sit
down with your program and *get some work done* without going through a
torturous installation procedure.


------------------------------------
"The child is MINE!" - Leonard McCoy

Leonard James Aka'ar?  Eek.